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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the mapping of the AMR generic frame format (3GPP TS 26.101) to the lu Interface 
(3GPP TS 25.415 [7]), the Uu Interface and the Nb Interface (3GPP TS 29.415). It further specifies the mapping of 
Enhanced Full Rate (GSM_EFR) coded speech and of PCM 64 kBit/s (ITU-T G.71 1 [9]) coded speech to the Nb 
Interface in a BICC-based circuit switched core network. 

The present document also specifies the mapping of Full Rate (GSM_FR) coded speech and of Half Rate (GSM_HR) 
coded speech to the Nb Interface in a BICC-based circuit switched core network. 

The present document also specifies the transport of the AMR Codec Types, the AMR-WB Codec Types, the 
GSM_EFR Codec, the GSM_FR Codec, the GSM_HR Codec and the ITU-T G.71 1 Codec over the A-Interface over IP 
(3GPP TS 48.002 [11]) and the Nb-Interface in a SIP-I -based circuit switched core network (3GPP TS 23.231 [12]). 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document the following terms and definitions apply: 

AMR Generic Frame Interface: this interface transports the AMR IFl generic frame as defined in 3GPP TS 26.101 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AAL2 ATM Adaptation Layer 2 

ACS Active Codec Set 

AMR Adaptive Multi-Rate 

AoIP A-Interface user plane transport over RTP/UDP/IP 

AS Access Stratum 

ATM Asynchronous Transfer Mode 

BFH Bad Frame Handling 

CDMA Code Division Multiple Access 

CMI Codec Mode Indication 

CMR/CMC Codec Mode Request or Codec Mode Command 

CN Core Network 

DRC Downlink Rate Command 

FDD Frequency Duplex Division 

FQC Frame Quality Classification (lu Interface) 

FQI Frame QuaUty Indication (AMR IF 1 ) 

GSM Global System for Mobile communications 

ITU-T International Telecommunication Union - Telecommunication standardisation sector 

MGW Media GateWay 

NboIP Nb-Interface user plane transport over RTP/UDP/IP when SIP-I is used on Nc 

PCM Pulse Code Modulation, synonym for 64 kBit/s coded speech (see ITU-T G.711 [9]) 

PDC Personal Digital Communication 

PLMN Public Land Mobile Network 

QoS Quality of Service 

RAB Radio Access Bearer 

RAN Radio Access Network 

RF Radio Frequency 

RFC RAB sub -flow Combination 

RFCI RFC Indicator 

RFCS RFC Set 

RX Receive 

SCR Source Controlled Rate 

SDU Source Data Unit 

SID Silence Insertion Descriptor 

SMpSDU Support Mode for Predefined SDU sizes 

SPD SPeech Decoder 

SPE SPeech Encoder 

TC Transcoder 

TDD Time Duplex Division 

TDMA Time Division Multiple Access 

TFO Tandem Free Operation 

TrFO Transcoder Free Operation 

TX Transmit 

UE User Equipment (terminal) 

URC Uplink Rate Command 



General 



The lu-Interface is defined in two different variants for speech telephony, 

a) for the ATM bearer with lu-framing and 

b) for the IP bearer with lu-framing. 

The Nb-Interface is defined in three different variants for speech telephony, 

a) for the ATM bearer with Nb-framing in a BICC -based Core Network, 

b) for the IP bearer with Nb-framing in a BICC -based Core Network and 

c) for the IP bearer with RTP packetization in a SIP-I -based Core Network, also called NboIP. 
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The mapping of the AMR Speech Codec parameters to the lu interface specifies the frame structure of the speech data 
exchanged between the RNC and the TC inside the MGW in case of normal operation. This mapping is independent 
from the radio interface in the sense that it has the same structure for both FDD and TDD modes of the UTRAN. 

The mapping between the Speech Codec and the Radio Access Network within the UE is not an open interface and 
need not to be detailed. 

The mapping on the Nb Interface in a BICC based Core Network is identical to the one on the lu Interface in case of 
Transcoder Free Operation, with the MGW relaying the SDUs unaltered between lu and Nb Interfaces. 

PCM coded speech is mapped onto the Nb-Interface in packets of 40 octets (5ms packetization time) or 160 octets 
(20ms packetization time). With Nb-framing (i.e. in a BICC -based Circuit Switched Core Network, IP or ATM) the 
default packetization time for PCM-coded speech is 5ms; 20ms is an additional option. For NboIP (i.e. RTP 
packetization in a SIP-I -based Circuit Switched Core Network) the default packetization time for PCM-coded speech is 
20ms; 5 ms is an additional option. 

The packetization time of PCM-coded speech for AoIP is 20ms without any other option. 

For the 3GPP Codec Types (GSM_FR, GSM_HR, GSM_EFR, AMR and AMR-WB) the framing is always 20ms and 
also the packetization time is 20ms in all versions of the Nb-Interface and the A-Interface over IP. The mapping of 
GSM_FR, GSM_HR and GSM_EFR Speech Codec parameters is defined on the A Interface over IP and all versions of 
the Nb-Interface, but not on the lu Interface. 
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RAB aspects 



During the RAB Assignment procedure initiated by the CN to establish the RAB for AMR, the RAB parameters are 
defined. The AMR RAB is estabHshed with one or more RAB co-ordinated sub-flows with predefined sizes and QoS 
parameters. In this way, each RAB sub-flow Combination corresponds to one AMR fi^ame type. For AMR, the first 
RAB sub-flow (sub-flow 1) corresponds with the Class A bits. In case there are three RAB sub-flows, the third RAB 
sub-flow (sub-flow 3) corresponds with the Class C bits. On the lu interface, these RAB parameters define the 
corresponding parameters regarding the transport of AMR frames. 

Some of the QoS parameters in the RAB assignment procedure are determined from the Bearer Capability Information 
Element used at call set up. These QoS parameters as defined in [3], can be set as follows: 



Table 5-1 : Example of mapping of BC IE into QoS parameters for UMTS AMR 



RAB service attribute 


RAB service attribute value 


Comments 


Traffic Class 


Conversational 




RAB Asymmetry Indicator 


Symmetric, bidirectional 


Symmetric RABs are used for uplink and 
downlink 


Maximum bit rate 


12.2 / 10.2 / 7.95 / 7.4 / 6.7 / 5.9 / 5.15 / 4.75 
kbit/s 


This value depends on the highest mode 
rate in the RFCS 


Guaranteed bit rate 


1 2.2 / 1 0.2 / 7.95 / 7.4 / 6.7 / 5.9 / 5.1 5 / 4.75 
kbit/s 


One of the values is chosen, depending 
on the lowest rate controllable SDU 
format (note 2) 


Delivery Order 


Yes 


(note 1) 


Maximum SDU size 


244/204/159/148/134/118/103/95 
bits 


Maximum size of payload field in lu UP, 
according to the highest mode rate in the 
RFCS 


Traffic Handling Priority 


Not applicable 


Parameter not applicable for the 
conversational traffic class, (note 1 ) 


Source statistics descriptor 


Speech 


(notel) 


SDU Parameters 


RAB sub-flow 1 
(Class A bits) 


RAB sub-flow 
2 (Class B 
bits) 


RAB sub- 
flow 3 
(Class C 
bits) 


The number of SDU, their number of RAB 
sub-flow and their relative sub-flow size is 
subject to operator tuning (note 3) 




SDU error ratio 


7* 10"' 


- 


- 


(note 3) 




Residual bit error ratio 


10-^ 


10-' 


5*10' 


(note 3 - applicable for every sub-flow) 




Delivery of erroneous SDUs 


yes 






Class A bits are delivered with error 

indication; 

Class B and C bits are delivered without 

any error indication. 




SDU format information 1-9 








(note 4) 




ISub-flow SDU size 1-9 


(note 5) 


(note 5) 


(note 5) 




NOTE 1 : These parameters apply to all UMTS speech codec types. 

NOTE 2: The guaranteed bit rate depends on the periodicity and the lowest rate controllable SDU size. 

NOTE 3: These parameters are subject to operator tuning. 

NOTE 4: SDU format information has to be specified for each AMR core frame type (i.e. with speech bits and comfort 

noise bits) included in the RFCS as defined in [2]. 
NOTE 5: The sub-flow SDU size corresponding to an AMR core frame type indicates the number of bits in the class A, 

class B and class C fields. The assigned SDU sizes shall be set so that the SCR operation is always possible. 



The RAB parameters shall be set so that the SCR operation is always possible. 

The conversational traffic class shall be used for the speech service, which is identified by the ITC parameter of the 

bearer capability information element in the SETUP message. This shall apply for all UMTS speech codec types. 

The parameters traffic class, transfer delay, traffic handling priority and source statistics descriptor shall be the same for 

all speech codec types applicable for UMTS. 
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6 lu Interface User Plane (RAN) 

The data structure exchanged on the lu interface are symmetrical, i.e. the structure of the uplink data frames is identical 
to that of the downlink data frames. 

6.1 Frame structure on the lu UP transport protocol 

6.1.1 Initialisation 

At the initialisation of the SMpSDU mode of operation, several parameters are set by the CN. The initialisation 
procedure is described in [1]. 

- RFCS: 

In the case of AMR, the RFCS corresponds to the Active Codec Set (ACS) plus potentially SCR authorised in 
the communication. Annex A of [1] gives an illustration of the usage of RFCI for AMR speech RAB. RFCS 
used in downlink may differ from that in uplink. 

Delivery of erroneous SDUs: 

This parameter shall be set to YES. Erroneous speech frames may be used to assist the error concealment 
procedures. Therefore, according to [1], PDU type (containing a payload CRC) shall be used for transport of 
AMR data. 

6.1 .2 Time Alignment Procedure 

The TC should adjust the timing of the speech data transmission in downlink direction according to the time alignment 
frames sent by the RNC. 

Time alignment procedure shall be dismissed in case of TFO and TrFO. 



6.2 Mapping of the bits 



The mapping of the bits between the generic AMR frames and the PDU is the same for both uplink and downlink 

frames. 

The following table gives the correspondence of the bit fields between the generic AMR frames at the TC interface and 
the PDU exchanged with the lu transport layer. 

Table 6-1 : Mapping of generic AMR frames onto lu PDUs 



PDU field 


Corresponding field within the 
generic AMR frame 


Comment 


PDU Type 


N/A 


Type 


Frame Number 


N/A 




FQC 


Frame Quality Indicator 




RFCI 


Frame Type 




Payload CRC 


N/A 




Header CRC 


N/A 










Payload Fields (N Sub-flows) 


Class A or SID payload ; 
Class B 1 
Class C : 


SDU#1 


Most important speech bits come first Mandatory 


sbu#2 


Next bits follow i^Optional 








i^Optional 


SDU#N 


Least important speech bits jOptional 
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The number of RAB sub-flows, their corresponding sizes, and their attributes such as "DeHvery of erroneous SDUs" 
shall be defined at the RAB establishment and signalled in the RANAP RAB establishment request, as proposed in 
clause 5. The number of RAB sub-flows is corresponding to the desired bit protection classes. The total number of bits 
in all sub-flows for one RFC shall correspond to the total number given in 3GPP TS 26.101, generic AMR frame, 
format IFl, for the corresponding Codec Mode, respectively Frame Type. 

Guidance for setting the number of bits in each RAB sub-flow according to their relative subjective importance is given 
in 3GPPTS 26.101. 

The following two tables are examples of mapping of RAB sub-flows. 

Table 6-2 gives three examples of sub-flow mapping. 

The RFCI definition is given in order of increasing SDU sizes. 

Example 1 describes Codec Type UMTS_AMR, with all eight codec modes foreseen in the Active Codec Set 
(ACS) and provision for Source Controlled Rate operation (SCR). In this example. Blind Transport Format 
Detection is supported and the sub-flow mapping follows the 26.101 class division guidance. 

Example 2 describes Codec Type GSM_EFR, with one codec mode, including SCR. 

- Example 3 describes Codec Type FR_AMR, including AMR SCR 

Table 6-2: Example for AMR with SCR and three sub-flows, according to subjective class division 

indication of 3GPP TS 26.101 



UMTS AMR 


GSM EFR 


FR AMR 


RAB sub-flows 


Total size of 
bits/RAB sub- 
flows 
combination 
(Mandatory) 


Source rate 


RFCI 
Example 1 


RFCI 
Example 2 


RFCI 
Example 3 


RAB sub- 
flow 1 
(Optional) 


RAB sub- 
flow 2 
(Optional) 


RAB sub- 
flow 3 
(Optional) 


2 




2 


42 


53 





95 


AMR 4,75 kbps 


3 






49 


54 





103 


AMR 5,15 kbps 


4 




3 


55 


63 





118 


AMR 5,9 kbps 


5 




4 


58 


76 





134 


AMR 6,7 kbps 


6 






61 


87 





148 


AMR 7,4 kbps 


7 






75 


84 





159 


AMR 7,95 kbps 


8 




5 


65 


99 


40 


204 


AMR 10,2 kbps 


9 


2 




81 


103 


60 


244 


AMR 12,2 kbps 


1 




1 


39 








39 


AMR SID 




1 




43 








43 


GSM-EFRSID 



Table 6-3 gives one example of sub-flow mapping that supports Equal Error Protection. 
The RFCI definition is given in order of increasing SDU sizes. 

Example 4 describes Codec Type PDC_EFR and the corresponding Source Controlled Rate operation (SCR). 
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Table 6-3: Example of SDU sizes for PDC_EFR with SCR and Equal Error Protection 



PDC EFR 


RAB sub-flow 


Total size of 

bits/RAB sub-flows 

combination 

(Mandatory) 


Source rate 


RFCI 
Example 4 


RAB sub- 
Flow 1 
(Mandatory) 




95 


95 


AMR 4,75kbps 




103 


103 


AMR 5,15kbps 




118 


118 


AMR 5,9kbps 


2 


134 


134 


AMR 6,7kbps 




148 


148 


AMR 7,4kbps 




159 


159 


AMR 7,95kbps 




204 


204 


AMR 10,2kbps 




244 


244 


AMR 12,2kbps 




39 


39 


AMR SID 




43 


43 


GSM-EFRSID 




38 


38 


TDMA-EFRSID 


1 


37 


37 


PDC-EFRSID 



6.3 



Frame handlers 



lu PDU Frame handling functions are described in 3GPP TS 25.415 [1]. This sections describe the mandatory frame 
handling functions at the AMR Generic frame interface. 

6.3.1 Handling of frames from TC to lu interface (downlink) 

The frames from the TC in generic AMR frame format IFl are mapped onto the lu PDU as follows. 

6.3.1 .1 Frame Quality Indicator 

The Frame Quality Indicator (FQI) from the TC is directly mapped to the Frame Quality Classification (FQC) of the lu 
frame according to Table 6-4. 

Table 6-4: FQI AIVIR to FQC lu PDU mapping 



FQI AMR 


FQI value 

(1 bit) 


FQC PDU 


FQC value 

(2 bit) 


GOOD 


1 


GOOD 


00 


BAD 





BAD 


01 



6.3.1.2 



Frame Type 



The received Frame Type Index 1 is mapped onto the RFCI j thanks to the assigned RFCS table: the correspondence 
between Codec Mode, Frame Type Index 1 and RFCI j is defined at RAB assignment. 

6.3.1 .3 Codec Mode Indication 

The Codec Mode Indication is not used. 



6.3.1.4 



Codec Mode Request 



Codec Mode Request (CMR) in downlink direction is forwarded to the rate control procedure when it changes, or when 
it is commanded so by the TC in case of TFO, see 3G TS 28.062. 
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6.3.1 .5 Optional internal 8 bits CRC 

The internal AMR Codec CRC is not used on the lu interface. 

6.3.1 .6 Mapping of Speech or Comfort Noise parameter bits 

Let us define the N payload fields of the N sub-flows for RFCI j as follows: 

Ui(k) shall be the bits in sub-flow i, for k =1 to Mi 

Mi shall be the size of sub-flow i, for i = 1 to N 

d(k) shall be the bits of the speech or comfort noise parameters of the corresponding Frame Type 1 in decreasing 
subjective importance, as defined in the generic AMR frame format IFl, see TS 26.101 [2]. 

Then the following mapping in pseudo code applies: 

Ui(k) = d(k-l) withk=l, ...Mi 

U2(k) = d(k-lH-Mi) withk=l, ... M2 

U3(k) = d(k-lH-M2) withk=l, ...M3 



UN(k) 



d(k-l + Mn.i) 



with k = 1 



Mn 



6.3.2 Handling of frames from lu interface to TC (uplink) 

The uplink lu frames are mapped onto generic AMR frames, format IFl, as follows. 



6.3.2.1 



Frame Quality Indicator 



At reception of lu PDU the lu frame handler function set the Frame Quality Classification according to the received 
FQC, Header-CRC check, and Payload-CRC check (see 25.415). AMR Frame Type and Frame Quality Indicator are 
determined according to the following table: 

Table 6-5: FQC lu PDU type to AMR FQI and AMR Frame Type mapping 



FQC 


FQC value 

(2 bits) 


Resulting 
FQI 


FQI value 

(1 bit) 


resulting 
Frame Type 


GOOD 


00 


GOOD 


1 


from RFCI 


BAD 


01 


BAD 





NO_DATA 


BAD Radio 


10 


BAD 





from RFCI 


Reserved 


11 


BAD 





Reserved 



6.3.2.2 Frame Type 

The received RFCI j is mapped onto the Frame Type Index 1 thanks to the RFCS table. 

6.3.2.3 Codec Mode Indication 

The Codec Mode Indication is not used. 
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6.3.2.4 Codec Mode Request 

The received Downlink Rate Control command (DRC) is mapped onto the Codec Mode Request (CMR) towards the 
AMR Codec. In case a new DRC is received it is mapped into the corresponding CMR of the generic AMR frame 
format. It is remembered by the TC until the next DRC is received. In each new frame that is sent to the AMR Codec, 
the stored CMR is resent, in order to control the Codec Mode for the downlink direction. 

6.3.2.5 Optional internal 8 bits CRC 

The internal AMR Codec CRC is not used on the lu interface. 

6.3.2.6 Speech and Comfort noise parameter bits 

The speech and Comfort noise parameter bits are mapped from the sub-flows to the payload of the generic AMR frames 
with the reverse function of clause 6.3.1.6. 



Uu Interface User Plane (UE) 



The interface between the UE AMR speech codec (see 3GPP TS 26.101) and the Radio Access Network is an internal 
UE interface and is not detailed. The mapping is corresponding to the mapping described in clause 6 for the lu interface. 

Even though the details of Uu interface are not detailed, there are some functional requirements for the UE that need to 
be considered, when an AMR codec type (i.e. UMTS AMR2) is being used in a conversational speech call. These 
requirements are related to the mapping of AMR Generic frame format handling functions. The requirements are 

1 . The set of available codec modes (bitrates) that the UE may use are configured by UTRAN. The UE shall 
select, from the configured set of codec modes, a mode that is supported by the current TX power conditions as 
defined in 3GPP TS25.133. The highest available mode should be used for best speech quality. 

2. The lowest configured codec mode is always to be considered supported. 

3. When the codec mode is being adapted during a call, the used mode should be changed in a step-by-step 
fashion within the configured set of codec modes, i.e. by stepping one mode up or down within the configured 
set. This avoids disruptions on AMR decoding in GSM side, if TFO or TrFO operation is ongoing. 



8 Nb Interface User Plane (CN) of a BICC-based 

Circuit Switched Core Network 

The data structures exchanged on the Nb interface are symmetrical, i.e. the structures of the sent and received data 
frames are identical. 

The Nb-Interface is defined in a BICC-based Core Network in two different variants, a) for the ATM bearer with Nb- 
framing, b) for the IP bearer with Nb-framing. The Nb-framing and the use of PDU Type for the speech payload and 
PDU Type 14 [7] for AMR Rate Control is common for both versions of the Nb-Interface here. These two versions also 
share the principle of "Nb_Init", where the Nb-Interface is initialized on User Plane level and where the Initial Codec 
Mode for AMR and/or AMR-WB is signalled. 

8.1 Frame structure on the Nb UP transport protocol 

Delivery of erroneous SDUs for AMR- and AMR-WB-coded speech, as well as for GSM_FR-, GSM_HR-, GSM_EFR- 
coded speech and for PCM-coded speech on the Nb-Interface shall be set to: "YES" in a BICC-based Circuit Switched 
Core Network. Erroneous speech frames may be used to assist the error concealment procedures. Therefore, according 
to [1] and [7], PDU Type (with payload CRC) shall be used for the transport of AMR, AMR-WB, GSM_FR, 
GSM_HR and GSM_EFR coded speech on the Nb interface. 
PDU Type (with payload CRC) shall be used for the transport of PCM coded speech on the Nb interface, too. 
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8.1.1 Initialisation 

The initialisation procedure is used for support mode. At the initialisation several parameters are set by the CN. The 
initialisation procedure for the Nb Interface is described in [7]. 

8.1 .2 Time Alignment Procedure 

The handling of Time Alignment on the Nb Interface is described in [7]. 
The Time alignment procedure shall be dismissed in case of TFO and TrFO. 

8.1 .3 SID Frame Generation 

All 3GPP Codec Types include a standardized Discontinuous Transmission (DTX) with Voice Activity Detection, 
Silence Description (by SID frames) and Comfort Noise Generation to fill the speech pauses. If speech inactivity is 
detected by the Encoder, then (speech) frames are not transmitted, but the transmission is suspended in order to save 
battery life time in the mobile station, reduce interference on the radio interface and reduce load on all links. The 
receiving Decoder fills these transmission pauses with Comfort Noise to minimize the contrast between pauses and 
active speech. Silence Descriptor (SID) frames need to be send during speech inactivity to keep the Comfort Noise 
decently well aligned with the background noise at sender side. This is especially important at the onset of the next 
talkspurt and therefore SID frames should not be too old, when speech starts again. 

The generation of SID frames for the AMR and AMR-WB families of Codecs is determined by the Speech Encoder as 
specified in TS 26.093 [31], respectively TS 26.193 [32]. The radio subsystem does not influence this timing! SID 
frames come during speech pauses in uplink and downlink about every 160ms. Also an AMR Encoder in the Media 
Gateway generates and sends SID frames about every 160ms. 

The generation of SID frames for GSM_FR, GSM_HR and GSM_EFR in the GSM radio network is determined by the 
GSM mobile station and the GSM radio subsystem, not primarily by the Speech Encoder! SID frames come during 
speech pauses in uplink from the mobile station about every 480ms. In downlink to the mobile station, when they are 
generated by the Speech Encoder of the GSM radio subsystem, SID frames are sent every 20ms to the GSM base 
station, which then picks only one every 480ms for downlink radio transmission. For other applications, like transport 
over Nb, it is more appropriate to send the SID frames less often than every 20ms, but 480ms may be too sparse. As a 
compromise it is recommended that an Encoder in the Media Gateway should generate and send SID frames every 
160ms. 

8.2 Mapping of the bits 

8.2.1 Mapping for AMR frames 

The mapping of the bits between the generic AMR frames and the PDU for the Nb Interface is identical to the mapping 
on the lu Interface. In case of TrFO the MGW relays the AMR frames from the lu Interface unaltered to the Nb 
Interface and vice versa, as described in [7]. 

8.2.2 Mapping for PCM Coded Speech 

The mapping for the PCM coded speech in 5ms frames on the Nb Interface shall be as defined in Table 8-1. 
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Table 8-1 : Mapping of PCM Coded Speech in 5 ms frames onto Nb PDU, Type 



PDU field 


Comment 


PDU Type 


Type (with Payload CRC) 


Frame Number 


as defined in [7] 


FQC 


set to "good" 


RFCI 


initialise by MOW, see [7], 
one value required 


Header CRC 


as defined in [7] 


Payload CRC 


as defined in [7] 






Payload Field 


320 bits of PCIVI coded speech, 
in accordance with [8]. 



The mapping for the PCM coded speech in 20ms frames on the Nb Interface shall be as defined in Table 8-2. 
Table 8-2: Mapping of PCM Coded Speech in 20ms frames onto Nb PDU, Type 



PDU field 


Comment 


PDU Type 


Type (with Payload CRC) 


Frame Number 


as defined in [7] 


FQC 


set to "good" 


RFCI 


initialised by MGW, see [7], 
one value required 


Header CRC 


as defined in [7] 


Payload CRC 


as defined in [7] 






Payload Field 


4x320 bits of PCM coded speech, 
in accordance with [8]. 



5ms is the default packetization time to be supported for PCM encoded speech over Nb in a BICC based Core Network. 
20ms is an additional optional packetization time for PCM encoded speech in a BICC based Core Network over IP Nb 
bearer that may be negotiated during bearer establishment as specified in [10]. 

NOTE: the use of 20ms packetization time will result in some call scenarios in higher delays over the speech 

path compared to the 5ms packetization time. This potentially higher delay should be taken into account 
in the overall end to end (ear to mouth) delay budget. 



8.2.3 Mapping for GSM_EFR frames 



The mapping of the bits between the generic GSM_EFR frames and the PDUs for the Nb Interface follows the same 
principles as the mapping of AMR frames. The PDU for the GSM_EFR speech frame is identical to the PDU for AMR 
Mode 12.2 kbps. 

The PDU for the GSM_EFR SID frame is similar to the PDU for AMR SID, with 43 instead of 39 bits in the payload 
field. The contents of GSM_EFR SID is the Comfort Noise Parameter set (s(i)) as defined in [36]. The Comfort noise 
parameters are computed as described in [30] by the GSM_EFR speech encoder and are denoted as s(i) = 
{s(l),i(2),...,s(38), s(87),s(88),...,s(91)}. The notation s(i) follows that of [36] (Table 6). The notation d(j) = {d(l) ... 
d(43) } of the SID frame is local to the present document and is formed as defined by the pseudo code below. 

for; = 1 to 38 

d(j) := s(jy, I* LSP parameters in s{\) to i(38) */; 

for; = 39 to 43 

dij) := i(/'+48); /* fixed codebook gain parameter in s(%7)-s{9\) */ 

The payload within the PDU shall be the vector d(j) constructed above. The first bit in the vector d(j) shall be supplied 
first in the payload within the PDU. 

NOTE: The Payload field for Nb frames for GSM_EFR in a BICC -based Circuit Switched Core Network is filled 
differently to the Payload field in RTP Packets according to RFC3551 [17], used in AoIP and NboIP. 
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8.2.4 Mapping for GSM_FR frames 

The mapping of GSM_FR-coded speech in 20ms frames on the Nb Interface shall be as defined in Table 8.2.4.1. 
Table 8.2.4.1 : Mapping of GSMFR-coded speech in 20ms frames onto Nb PDU, Type 



PDU field 


Comment 


PDU Type 


Type (with Payload CRC) 


Frame Number 


as defined in [7] 


FQC 


see below 


RFCI 


initialise by IVIGW, see [7], two values required (Speech and SID) 


Header CRC 


as defined in [7] 


Payload CRC 


as defined in [7] 






Payload Field 


4 bits for "signature", 260 bits for Speech frames and 42 bits for SID frames, see 
below 



Payload field: 

The 260 bits of GSM_FR-coded speech (bl...b260) are defined in TS 46.010, chapter 1.7. They and a "signature" are 
copied into the 33 octets of the Payload field as follows. The four most significant bits (bit 8 ... .5) of the first octet (octet 
1) of the Nb Payload field are set to a "signature" of ObllOl = OxD. Then the four most significant bits (b6...b3) of the 
first GSM_FR parameter (LAR 1) are copied into the next bits (bit 4. . . 1) of the first octet. The two least significant bits 
of the first GSM_FR parameter (LAR 1) are copied into the next octet (octet 2) into the 2 MSBs (bit 8... 7), and so on. 
Each GSM_FR parameter is copied bit by bit with its most significant bit first. The least significant bit of the last 
GSM_FR parameter (b258 of RPE-pulse no. 13) is placed in the LSB (bit 1) of octet 33. 

The GSM_FR SID frames are defined in chapter 5.2 of [28] and in chapter 1.7 of [23] and are denoted as 
b(i) = {b(l),b(2),...,b(36), b(48),b(49),...,b(53)}. Each GSM_FR SID parameter is copied bit by bit with its most 
significant bit first. The notation d(j) = {d(l) ... d(42)} of the SID frame is local to the present document and is formed 
by the pseudo code below. 

for j = 1 to 36 

d(j) := b(jy, /* averaged log area coefficients in b(l) to b(36) */; 

for; = 37 to 42 

d(j) := b(j+l 1); /* averaged block amplitude values in b(4^)-b(53) */ 

The payload within the PDU shall be the vector d(j) constructed above. The first bit in the vector d(j) shall be supplied 
first in the payload within the PDU. 

NOTE: The Payload field for Nb frames for GSM_FR in a BICC-based Circuit Switched Core Network is filled 
differently to the Payload field in RTP Packets according to RFC3551 [17], used in AoIP and NboIP. 

The FQC bit is set by the MGW depending on the call case: 

1. FQC is set to "good", if the GSM_FR-compression and coding is performed within the MGW 

2. FQC is set to "good", if GSM_FR-coded speech is received without frame quality indication 

3. FQC is derived from the input frame, if FQC or a similar frame quality indication is specified there. 

In case of GSM_FR-coded speech received via TFO frames (see TS 28.062 [5]) the FQC bit is derived from 
the "Bad Frame Indication" (BFI) of these TFO frames. Speech frames and SID frames marked with BFI set to 
"good" shall be sent with FQC set to "good". Speech frames and SID frames marked with BFI set to "bad" 
shall not be sent in order to save bandwidth on Nb. 

8.2.5 Mapping for GSM_HR frames 

The mapping of GSM_HR-coded speech in 20ms frames on the Nb Interface shall be as defined in Table 8.2.5.1. 
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Table 8.2.5.1 : Mapping of GSMHR-coded speech in 20ms frames onto Nb PDU, Type 



PDU field 


Comment 


PDU Type 


Type (with Payload CRC) 


Frame Number 


as defined in [7] 


FQC 


see below 


RFCI 


initialise by IVIGW, see [7], two values required (Speech and SID) 


Header CRC 


as defined in [7] 


Payload CRC 


as defined in [7] 






Payload Field 


112 bits for Speech frames and 33 bits for SID frames, see below 



The 1 12 bits of GSM_HR-coded speech (bl . . .bl 12) are defined in TS 46.020, Annex B, in the order of occurrence. The 
first bit (bl) of the first parameter is placed in bit 8 (the MSB) of the first octet (octet 1) of the Nb Payload field; the 
second bit is placed in bit 7 of the first octet and so on. The last bit (bl 12) is placed in the LSB (bit 1) of octet 14. 

The GSM_HR SID frames are defined in [24] and [29] and are denoted as b(i) = {b(l),b(2),...,b(33)}. The notation d(j) 
= {d(l) ... d(33)} of the SID frame is local to the present document and is formed by the pseudo code as follows. 

fory = 1 to 5 

d(j) := bij); I* RO parameter in b{l) to b{5) */; 

for j = 6 to 16 

dij) ■= bij); I* LPCl parameter in b{6)-b{\6) */ 

for7= 17 to 25 

dij) ■= bij); I* LPC2 parameter in b(\l)-b{25) */ 

for j = 26 to 33 

d{j) ■= bij); I* LPC3 parameter in bi26)-bi33) */ 

The payload within the PDU shall be the vector d(j) constructed above. The first bit in the vector d(j) shall be supplied 
first in the payload within the PDU. 

NOTE: The Payload field for Nb frames for GSM_HR in a BlCC-based Circuit Switched Core Network is filled 
similar, but not identical to the Payload field in RTP Packets according to [22], used in AolP and NbolP. 

The FQC bit is set by the MGW depending on the call case: 

1. FQC is set to "good", if the GSM_HR-compression and coding is performed within the MGW. 

2. FQC is set to "good", if GSM_HR-coded speech is received without frame quality indication. 

3. FQC is derived from the input frame, if FQC or a similar frame quality indication is specified there. 

In case of GSM_HR-coded speech received via TFO frames (see TS 28.062 [5]) the FQC bit is derived 
from the "Extended control bits" (XCl to XC5) for 8kbps submultiplexing (specified in TS 48.061, chapter 
5.2.4.1.1 and partly reprinted here for ease of reading) as defined in table 8.2.5.2. 
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Table 8.2.5.2: The FQC bit for GSM HR-coded Nb frames derived from TFO frames 



FQC 


XC1 


XC2 


XC3 


XC4 


XC5 


Meaning (in Abis frames with 8kbps submultiplexing) 


good 

















Good speech frame with UFI = 

(BFI=0, SID=0, TAF=1) 
(BFI=0, SID=0, TAF=0) 


bad* 














1 


Unreliable speech frame (if speech decoder is in speech decoding mode) 
or unusable frame (if speech decoder is in comfort noise insertion mode) 
with UFI = 1 

(BFI=0, SID=0, TAF=1) 

(BFI=0, SID=0, TAF=0) 


good 











1 





Valid SID frame with UFI = 

(BFI=0, S1D=2, TAF=1) 
(BFI=0, SID=2, TAF=0) 


bad 











1 


1 


Invalid SID frame with UFI = 1 

(BFI=0, SID=2, TAF=1) 
(BFI=0, S1D=2, TAF=0) 


bad 





1 











Invalid SID frame at TAF=0 with UFI = 
(BFI=0, SID=1,TAF=0) 
(BFI=1,SID=1,TAF=0) 
(BFI=1,SID=2, TAF=0) 


bad 





1 








1 


Invalid SID frame at TAF=0 with UFI = 1 
(BFI=0, SID=1,TAF=0) 
(BFI=1,SID=1,TAF=0) 
(BFI=1,SID=2, TAF=0) 


bad 





1 





1 





Invalid SID frame at TAF=1 with UFI = 
(BFI=0, SID=1,TAF=1) 
(BFI=1,SID=1,TAF=1) 
(BFI=1,SID=2, TAF=1) 


bad 





1 





1 


1 


Invalid SID frame at TAF=1 with UFI = 1 
(BFI=0, SID=1,TAF=1) 
(BFI=1,SID=1,TAF=1) 
(BFI=1,SID=2, TAF=1) 


bad* 





1 


1 








Bad speech frame or unusable frame at TAF = with UFI = 
(BFI=1,SID=0, TAF=0) 


bad* 





1 


1 





1 


Bad speech frame or unusable frame at TAF = with UFI = 1 
(BFI=1,SID=0, TAF=0) 


bad* 





1 


1 


1 





Bad speech frame or unusable frame at TAF = 1 with UFI = 
(BFI=1,SID=0, TAF=1) 


bad* 





1 


1 


1 


1 


Bad speech frame or unusable frame at TAF = 1 with UFI = 1 
(BFI=1,SID=0, TAF=1) 



Speech frames and SID frames marked in Table 8.2.5.2 with FQC set to "good" shall be sent. 

Frames marked in Table 8.2.5.2 with FQC set to "bad*" or "bad" shall not be sent in order to save bandwidth on Nb. 

NOTE: the abbreviations "UFI" (unreliable frame indication), "BFI" (bad frame indication), "SID" (Silence 
Descriptor) and "TAF" (Time Alignment Flag) are defined in 3GPP TS 46.041 [25]. 



8.3 



Frame handlers 



Nb PDU Frame handling functions are described in [7]. 



Nb Interface User Plane (CN) of a SIP-I -based 
Circuit Switched Core Network 



9.1 



Overview 



The SIP-I -based Circuit Switched Core Network is specified in 3GPP TS 23.231 [12]. The User Plane in this Core 
Network is further specified in 3GPP TS 29.414 [10]. RTP is specified in IETF RFC 3550 [16]. 
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RTP is used in a SIP-I -based Circuit Switched Core Network as framing protocol at the Nb-Interface (without Nb- 
framing protocol). The rules for the usage of RTP and RTCP in 3GPP TS 29.414 [10] are applicable in combination 
with further Codec-specific rules provided in the present specification. 

Table 9.1.1 lists the applicable 3GPP Codec Types for a SIP-I -based Circuit Switched Core Network. Codecs for data 
transport are described in 3GPP TS 29.007 [13]. 

Table 9.1.1 Supported Codec Types in a SIP-I -based Circuit Switched Core Network 



Payload Type Name 


References 


Remarks 


Support 


audio/AMR 


IETF RFC 4867 [21] 


Applicable for FR AMR, 
HR AMR, OHR AMR, 
UMTS_AMR and UMTS_AMR2 


Mandatory. 
Not all AMR 
Configurations are 
mandatory. Some 
Configurations are 
preferred, see below. 


audio/AMR-WB 


IETF RFC 4867 [21] 


Applicable for FR AMR-WB, 
OHR AMR-WB, OFR AMR- 
WB, UMTS_AMR-WB 


Optional. 

AMR-WB is mandatory, if 
WB speech is supported. 
Not all WB Configurations 
are mandatory, see below 


audio/GSM_EFR 


IETF RFC 3551 [17] 


Useful if an A-interface over IP is 
attached or TFO is used. 


Optional 


audio/GSM_FR 


IETF RFC 3551 [17] 


Useful if an A-interface over IP is 
attached or TFO is used. 


Optional 


audio/GSM_HR 


[22] 


Useful if an A-interface over IP is 
attached or TFO is used. 


Optional 


audio/PCMA 


IETF RFC 3551 [17] 


ITU-T G.71 1 Alaw 


Mandatory 


audio/PCMU 


IETF RFC 3551 [17] 


ITU-T G.711 ulaw 


Mandatory 


audio/telephone-event 


IETF RFC 4733 [20] 


Used to transport DTMF 


Mandatory 



The RTP "Payload Type" number for the Nb-Interface is either static (for PCMA, PCMU and GSM_FR) or determined 
by the MSC-S (dynamic Payload Type). 

9.1 .1 Time Alignment Procedure 

Time Alignment (and AMR Phase Alignment) is not specified in a SIP-I -based Circuit Switched Core Network. 

9.1 .2 SID Frame Generation 

All 3GPP Codec Types include standardized Discontinuous Transmission (DTX) with Voice Activity Detection, 
Silence Description (by SID frames) and Comfort Noise Generation to fill the speech pauses. If speech inactivity is 
detected by the Encoder, then (speech) frames are not transmitted, but the transmission is suspended in order to save 
battery life time in the mobile station, reduce interference on the radio interface and reduce load on all links. The 
receiving Decoder fills these transmission pauses with Comfort Noise to minimize the contrast between pauses and 
active speech. Silence Descriptor frames need to be send during speech inactivity to keep the Comfort Noise decently 
well aligned with the background noise at sender side. This is especially important at the onset of the next talkspurt and 
therefore SID frames should not be too old, when speech starts again. 

The generation of SID frames for the AMR and AMR-WB families of Codecs is determined by the Speech Encoder as 
specified in TS 26.093 [31], respectively TS 26.193 [32]. The radio subsystem does not influence this timing! SID 
frames come during speech pauses in uplink and downlink about every 160ms. Also an AMR Encoder in the Media 
Gateway generates and sends SID frames about every 160ms. 

The generation of SID frames for GSM_FR, GSM_HR and GSM_EFR in the GSM radio network is determined by the 
GSM mobile station and the GSM radio subsystem, not primarily by the Speech Encoder! SID frames come during 
speech pauses in uplink from the mobile station about every 480ms. In downlink to the mobile station, when they are 
generated by the Speech Encoder of the GSM radio subsystem, SID frames are sent every 20ms to the GSM base 
station, which then picks only one every 480ms for downlink radio transmission. For other applications, like transport 
over Nb, it is more appropriate to send the SID frames less often than every 20ms, but 480ms may be too sparse. As a 
compromise it is recommended that an Encoder in the Media Gateway should generate and send SID frames every 
160ms. 
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9.1.3 Initial Codec Mode 

NOTE: At the Nb-Interface in a SIP -I -based Core Network, direct RTP packetization without Nb-framing is 
applied. Therefore the use of PDU Type for the speech payload and PDU Type 14 [7] for AMR Rate 
Control is here not applicable. Also the principle of "Nb_Init" is not applicable for a SIP-I -based Core 
Network. 

The Initial Codec Mode for AMR and AMR-WB shall be derived by pre-defined rules from the AMR Configuration 
(Active Codec Set), see TS 45.009 [35], chapter 3.4.3 "Initial Codec Mode Selection at Call Setup and Handover". 

Start of extract from TS 45.009 [35] for information and ease of reading: 

"If the Initial Codec Mode is not signalled, then the default Initial Codec Mode is given by the following implicit 
rule. If the Active Codec Set contains: 

1 mode, then this shall be the Initial Codec Mode; 

2 or 3 modes, then the Initial Codec Mode shall be the most robust mode of the set (with lowest bit rate); 

4 modes, then the Initial Codec Mode shall be the second most robust mode of the set (with second 

lowest bit rate." 

End of extract from TS 45.009 [35]. 

In case of FR_AMR (Set 1), i.e. Config-NB-Code 1, see below, this is the AMR Mode with 5.90kbps. 



9.2 AMR 



AMR (FR_AMR, HR_AMR, OHR_AMR, UMTS_AMR and UMTS_AMR2) shall be packed according to IETF RFC 
4867 [21]. 

The AMR Codec Types can be used in conversational speech telephony services in a number of different Codec 
Configurations. The set of preferred AMR Codec Configurations is defined in TS 28.062 [5], Table 7.11.3.1.3-2. One of 
these preferred Configurations, Config-NB-Code 1, is recommended for TFO-TrFO harmonisation between GSM and 
UMTS networks. This Configuration shall be supported in a SIP-I based circuit switched core network to ensure 
interoperability with an AoIP -based ESS. However, it is recommended that nodes in the core network support all AMR 
modes for maximum interoperability. 

The bandwidth efficient mode of RFC 4867 shall be used. CRC and robust sorting shall not be applied. 

To avoid delay, a single frame (Speech or SID_FIRST or SID_UPDATE or ONSET) shall be included in one RTP 
packet. Interleaving (redundancy) shall not be used, and a packetization time of 20ms shall be applied. No_Data frames 
should not be sent, except when needed for urgent Rate Control. 

Nodes in the core network (e.g. MGWs) transcoding between AMR and some other Codec shall observe the following 
rules: 



• 



An AMR Encoder (sender) in the core network shall obey an AMR Codec Mode change period of 40ms, 
i.e. Codec Mode changes by the AMR Encoder (sender) in this core network node are only permissible at 
every second frame. This ensures maximum interoperability with any AMR receiver. 

An AMR Decoder (receiver) shall, however, be able to accept Codec Mode changes at any time. 
Variations of the Codec Mode period in receive direction may happen due to handover or other events 
during a conversation. The UMTS_AMR Codec Type (only allowed in R99 UTRAN-only terminals) may 
change its Codec Mode any time. Other application of the AMR Codec Types (e.g. MTSI) may perform 
Codec Mode changes any time. This ensures maximum interoperability with any AMR sender. 

An AMR Encoder shall only change the Codec Mode to a neighbouring mode of the defined AMR 
Configuration (one step up or one step down), regardless which Rate Control command it receives. If 
necessary the AMR Encoder shall apply several Codec Mode changes in a row, if the received Rate Control 
command requests a change of more than one step. This ensures maximum interoperability with any AMR 
receiver, especially within GSM terminals. 
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• An AMR Decoder (receiver) shall, however, be able to accept Codec Mode changes in any step size. 
Variations of the Codec Mode in receive direction may happen due to handover or other events during a 
conversation. Other application of the AMR Codec Types (e.g. MTSI) may perform any Codec Mode 
changes. This ensures maximum interoperability with any AMR sender. 

• DTX (SCR) shall be supported in send and receive direction. 

AMR Rate Control shall use the CMR bits inside the RTF payload, both, in send and receive direction. RTCP shall not 
be used for AMR Rate Control in a CS core network. 

Rate Control Commands coming from an Nb-Interface of a BICC -based Core Network, or an lu-Interface, or an IMS- 
Interface, or an general VoIP-Interface, shall be converted to CMR and shall be send continuously inside RTF packets 
together with the next Speech or SID_FIRST or SID_UFDATE or ONSET frame. 

NOTE: In a SIF-I -based Circuit Switched Core Network no Nb-framing is applied and so also no "FDU Type 
14" [7] exists for Rate Control Commands. 

It is allowed to send an artificially inserted No_Data frame to transport an urgent CMR in RTF. Flease note that a GSM 
radio subsystem connected via AoIF can not send No_Data frames across the radio interface and will typically ignore 
such No_Data frames. The use of No_Data frames for CMR is especially helpful inside the Core Network at call setup 
to control the downlink mode for the Encoder inside the terminating MGW for the compression of the ringback tone or 
an announcement, when the originating MGW still blocks the speech path in forward direction to prevent fraud. 

9.3 AMR-WB 

AMR-WB (FR_AMR-WB, OHR_ AMR-WB, OFR_AMR-WB, UMTS_AMR-WB) shall be packed according to IETF 

RFC 4867 [21]. 

The AMR-WB Codec Types can be used in conversational speech telephony services in a number of different Codec 
Configurations. The set of AMR-WB Codec Configurations is defined in TS 26.103 [14], Table 5.7-1. One of these 
Configurations, Config-WB-Code 0, shall be supported by all nodes supporting the AMR-WB codec in a SIF-I based 
circuit switched core network to ensure interoperability. However, it is recommended that nodes in the core network 
support all AMR-WB modes for maximum interoperability. 

The bandwidth efficient mode of RFC 4867 [21] shall be used. CRC and robust sorting shall not be applied. 

To avoid delay, a single frame (Speech or SID_FIRST or SID_UPDATE or ONSET) shall be included in one RTF 
packet. Interleaving (redundancy) shall not be used, and a packetization time of 20ms shall be applied. No_Data frames 
should not be sent, except when needed for urgent Rate Control. 

Nodes in the core network (e.g. MGWs) transcoding between AMR-WB and some other Codec shall observe the 
following rules: 

• An AMR-WB Encoder (sender) in the core network shall obey an AMR-WB Codec Mode change period of 
40ms, i.e. Codec Mode changes by the AMR-WB Encoder (sender) in this core network node are only 
permissible at every second frame. This ensures maximum interoperability with any AMR-WB receiver. 

• An AMR-WB Decoder (receiver) shall, however, be able to accept Codec Mode changes at any time. 
Variations of the Codec Mode period in receive direction may happen due to handover or other events 
during a conversation. Other application of the AMR-WB Codec Types (e.g. MTSI) may perform Codec 
Mode changes any time. This ensures maximum interoperability with any AMR-WB sender. 

• An AMR-WB Encoder shall only change the Codec Mode to a neighbouring mode of the defined AMR- 
WB Configuration (one step up or one step down), regardless which Rate Control command it receives. If 
necessary the AMR-WB Encoder shall apply several Codec Mode changes in a row, if the received Rate 
Control command requests a change of more than one step. This ensures maximum interoperability with 
any AMR-WB receiver, especially within GSM terminals. 

• An AMR-WB Decoder (receiver) shall, however, be able to accept Codec Mode changes in any step size. 
Variations of the Codec Mode in receive direction may happen due to handover or other events during a 
conversation. Other application of the AMR-WB Codec Types (e.g. MTSI) may perform any Codec Mode 
changes. This ensures maximum interoperability with any AMR-WB sender. 
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• DTX (SCR) shall be supported in send and receive direction. 

AMR-WB Rate Control shall use the CMR bits inside the RTP payload, both, in send and receive direction. RTCP shall 
not be used for AMR-WB Rate Control in a CS core network. 

Rate Control Commands coming from an Nb-Interface of a BICC -based Core Network, or an lu-Interface, or an IMS- 
Interface, or an general VoIP-Interface, shall be converted to CMR and shall be send continuously inside RTP packets 
together with the next Speech or SID_FIRST or SID_UPDATE or ONSET frame. 

NOTE: In a SIP-I -based Circuit Switched Core Network no Nb-framing is applied and so also no "PDU Type 
14" [7] exists for Rate Control Commands. 

It is allowed to send an artificially inserted No_Data frame to transport an urgent CMR in RTP. Please note that a GSM 
radio subsystem connected via AoIP can not send No_Data frames across the radio interface and will typically ignore 
such No_Data frames. The use of No_Data frames for CMR is especially helpful on the AoIP -Interface in uplink and 
inside the Core Network at call setup to control the downlink mode for the Encoder inside the terminating MGW for the 
compression of the ringback tone or an announcement, when the originating MGW still blocks the speech path in 
forward direction to prevent fraud. 

9.4 GSM_EFR 

GSM_EFR shall be packed according to IETF RFC 3551 [17]. 

The coding of SID frames is based on the coding of Speech frames by setting the 95 bits of the so called "SID- 
Codeword" all to "1", see TS 46.062 [30]. 

To avoid delay, a single frame (Speech or SID) shall be included in one RTP packet. Interleaving (redundancy) shall not 
be used, and a packetization time of 20 ms shall be applied. No_Data frames shall not be sent. 

DTX shall be supported in send and receive direction. 

GSM_EFR frames received from some interface (e.g. a GSM radio interface via TFO) with a bad frame indication set to 
"bad" shall not be forwarded on the Nb-Interface in a SIP-I -based Circuit Switched Core Network, but silently 
discarded. 

NOTE: RFC 3551 [17] does not support the concept of Bad Frame Indication. 

9.5 GSM_FR 

GSM_FR shall be packed according to IETF RFC 3551 [17]. 

The coding of SID frames is based on the coding of Speech frames by setting the 95 bits of the so called "SID- 
Codeword" all to "0", see TS 46.012 [28]. 

To avoid delay, a single frame (Speech or SID) shall be included in one RTP packet. Interleaving (redundancy) shall not 
be used, and a packetization time of 20ms shall be applied. No_Date frames shall not be sent. 

DTX shall be supported in send and receive direction. 

GSM_FR frames received from some interface (e.g. a GSM radio interface via TFO) with a bad frame indication set to 
"bad" shall not be forwarded on the Nb-Interface in a SIP-I based Circuit Switched Core Network, but silently 
discarded. 

NOTE: RFC 3551 [17] does not support the concept of Bad Frame Indication. 

9.6 GSM_HR 

GSM_HR shall be packed according to [22]. 

The options specified in [22] are not applied inside the Circuit Switched Core Network, but set to pre-defmed values as 
follows: 
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A single frame (Speech or SID) shall be included in one RTP packet, FEC and Interleaving (redundancy) shall not be 
used, Encryption shall not be used, a packetization time of 20ms shall be applied. No_Data frames shall not be sent. 

DTX shall be supported in send and receive direction. 

GSM_HR frames received from some interface (e.g. a GSM radio interface via TFO) with a bad frame indication set to 
"bad" shall not be forwarded on the Nb-Interface in a SIP-I -based Circuit Switched Core Network, but silently 
discarded. 

NOTE: [22] does not support the concept of Bad Frame Indication. 

9.7 PCM 

PCMU and PCMA shall be packed according to IETF RFC 3551 [17]. 

The PCM packetization time for a SIP-I -based Core Network is negotiated via SDP. The mandatory, default value is 
20ms; 5ms is one other, optional value; no other packetization time shall be used. To avoid delay, a single frame of 
length equal to the packetization time shall be included in one RTP packet. Interleaving (redundancy) shall not be used. 

The usage of DTX for PCM-coded speech is not recommended for NboIP. 

9.8 Telephone-Event 

Telephony-Event (DTMF) shall be encoded according to IETF RFC 4733 [20]. 

The audio/telephone-event payload type in IETF RFC 4733 [20] with default events and default rate shall be used to 
encode DTMF, if compressed speech is used in a SIP-I -based Core Network. Only in case of PCM-coded speech on 
NboIP the Telephone-Event is optional, i.e. also inband DTMF tones may be used (see TS 23.231 [12]). 

10 A-lnterface User Plane over IP 
10.1 Overview 

The A interface User Plane over IP (AoIP) is standardised in the 3GPP TS 48-series (mainly in TS 48.008) [33] for the 
Control Plane and in TS 48. 103 [34] for the User Plane). 

For AoIP the same Codecs as described in Clause 9 are applicable, except telephone-event, see table 10.1.1. Those 
Codecs shall also be applied in the same manner as described in Clause 9, unless otherwise specified in the present 
Clause 10. 
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Table 10.1.1 Supported Codec Types for the A interface User Plane over IP 



Payload Type Name 


References 


Remarks 


Support 


audio/AMR 


IETF RFC 4867 [21] 


Applicable for FR AIVIR, 
HR_AMR, OHR_AMR 


Optional. 
Not all AMR 
Configurations are 
mandatory. Some 
Configurations are 
preferred, see chapter 9. 


audio/AMR-WB 


IETF RFC 4867 [21] 


Applicable for FR AMR-WB, 
OHR_AMR-WB, OFR_AMR-WB 


Optional. 

AMR-WB is mandatory, if 
WB speech is supported. 
Not all AMR-WB 
Configurations are 
mandatory, see chapter 9 


audio/GSM EFR 


IETF RFC 3551 [17] 




Optional 


audio/GSM FR 


IETF RFC 3551 [17] 




Mandatory 


audio/GSM HR 


[22] 




Optional 


audio/PCMA 


IETF RFC 3551 [17] 


ITU-T G.71 1 Alaw 


Optional 


audio/PCMU 


IETF RFC 3551 [17] 


ITU-T G.711 ulaw 


Optional 



The RTP "Payload Type" for AoIP is pre-determined by 3GPP TS 48.103 [34] for all Codec Types (static payload 
type). 

10.1.1 Time Alignment Procedure 

Time Alignment (and AMR Phase Alignment) is not specified for AoIP. 

1 0.1 .2 SID Frame Generation 

All 3GPP Codec Types include standardized Discontinuous Transmission (DTX) with Voice Activity Detection, 
Silence Description (by SID frames) and Comfort Noise Generation to fill the speech pauses. If speech inactivity is 
detected by the Encoder, then (speech) frames are not transmitted, but the transmission is suspended in order to save 
battery life time in the mobile station, reduce interference on the radio interface and reduce load on all links. The 
receiving Decoder fills these transmission pauses with Comfort Noise to minimize the contrast between pauses and 
active speech. Silence Descriptor frames need to be send during speech inactivity to keep the Comfort Noise decently 
well aligned with the background noise at sender side. This is especially important at the onset of the next talk spurt and 
therefore SID frames should not be too old, when speech starts again. 

The generation of SID frames for the AMR and AMR-WB families of Codecs is determined by the Speech Encoder as 
specified in TS 26.093 [31], respectively TS 26.193 [32]. The radio subsystem does not influence this timing! SID 
frames come during speech pauses in uplink and downlink about every 160ms. Also an AMR Encoder in the Media 
Gateway generates and sends SID frames about every 160ms. 

The generation of SID frames for GSM_FR, GSM_HR and GSM_EFR in the GSM radio network is determined by the 
GSM mobile station and the GSM radio subsystem, not primarily by the Speech Encoder! SID frames come during 
speech pauses in uplink from the mobile station about every 480ms. In downlink to the mobile station, when they are 
generated by the Speech Encoder of the GSM radio subsystem, SID frames are sent every 20ms to the GSM base 
station, which then picks only one every 480ms for downlink radio transmission. For other applications, like transport 
over the A-Interface, it is more appropriate to send the SID frames less often than every 20ms, but 480ms may be too 
sparse. As a compromise it is recommended that an Encoder in the Media Gateway should generate and send SID 
frames every 160ms. 

10.1.3 Initial Codec Mode 

The Initial Codec Mode for AMR and AMR-WB shall be derived by pre-defmed rules from the AMR Configuration 
(Active Codec Set), see TS 45.009 [35], chapter 3.4.3 "Initial Codec Mode Selection at Call Setup and Handover". 

Start of extract from TS 45.009 [35] for information and ease of reading: 

"If the Initial Codec Mode is not signalled, then the default Initial Codec Mode is given by the following implicit 
rule. If the Active Codec Set contains: 
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1 mode, then this shall be the Initial Codec Mode; 

2 or 3 modes, then the Initial Codec Mode shall be the most robust mode of the set (with lowest bit rate); 

4 modes, then the Initial Codec Mode shall be the second most robust mode of the set (with second 

lowest bit rate." 

End of extract from TS 45.009 [35]. 

In case of FR_AMR (Set 1), i.e. Config-NB-Code 1, see below, this is the AMR Mode with 5.90 kbps. 

10.2 AMR 

AMR (FR_AMR, HR_AMR, OHR_AMR) shall be packed according to IETF RFC 4867 [21]. 

The AMR Codec Types can be used in conversational speech telephony services in a number of different Codec 
Configurations. The set of preferred AMR Codec Configurations is defined in TS 28.062 [5], Table 7.11.3.1.3-2. One of 
these preferred Configurations, Config-NB-Code 1, is recommended for TFO-TrFO harmonisation between GSM and 
UMTS networks. This Configuration shall be supported in an AoIP supporting BSS and an AoIP supporting Circuit 
Switched Core Network to ensure interoperability. However, it is recommended that a BSS and Circuit Switched Core 
Network supports all AMR modes for maximum interoperability. 

The bandwidth efficient mode of RFC 4867 [21] shall be used. CRC and robust sorting shall not be applied. 

To avoid delay, a single frame (Speech or SID_FIRST or SID_UPDATE or ONSET) shall be included in one RTF 
packet. Interleaving (redundancy) shall not be used, and a packetization time of 20ms shall be applied. No_Data frames 
should not be sent downlink across AoIP, except to transport an urgent CMR in RTP. The use of No_Data frames for 
CMR is especially helpful on the AoIP-Interface in uplink and inside the Core Network at call setup to control the 
downlink mode for the Encoder inside the terminating MGW for the compression of the ringback tone or an 
announcement, when the originating MGW still blocks the speech path in forward direction to prevent fraud. 

Please note that a GSM radio subsystem can not send No_Data frames across the radio interface and will typically 
ignore such No_Data frames in downlink direction. 

DTX (SCR) shall be supported in send and receive direction. 

AMR Rate Control shall use the CMR bits inside the RTP payload, both, in send and receive direction. RTCP shall not 
be used for AMR Rate Control in a CS network. 

10.3 AMR-WB 

AMR-WB (FR_AMR-WB, OHR_AMR-WB, OFR_ AMR-WB) shall be packed according to IETF RFC 4867 [21]. 

The AMR-WB Codec Types can be used in conversational speech telephony services in a number of different Codec 
Configurations. The set of AMR-WB Codec Configurations is defined in TS 26.103 [14], Table 5.7-1. One of these 
Configurations, Config-WB-Code 0, shall be supported by all nodes supporting the AMR-WB codec in an AoIP- 
supporting BSS and an AoIP-supporting Circuit Switched Core Network to ensure interoperability. However, it is 
recommended that nodes in the Core Network support all AMR-WB modes for maximum interoperability. 

The bandwidth efficient mode of RFC 4867 [21] shall be used. CRC and robust sorting shall not be applied. 

To avoid delay, a single frame (Speech or SID_FIRST or SID_UPDATE or ONSET) shall be included in one RTP 
packet. Interleaving (redundancy) shall not be used, and a packetization time of 20ms shall be applied. No_Data frames 
should not be sent downlink across AoIP, except to transport an urgent CMR in RTP. The use of No_Data frames for 
CMR is especially helpful on the AoIP-Interface in uplink and inside the Core Network at call setup to control the 
downlink mode for the Encoder inside the terminating MGW for the compression of the ringback tone or an 
announcement, when the originating MGW still blocks the speech path in forward direction to prevent fraud. 

Please note that a GSM radio subsystem can not send No_Data frames across the radio interface and will typically 
ignore such No_Data frames in downlink direction. 

DTX (SCR) shall be supported in send and receive direction. 
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AMR-WB Rate Control shall use the CMR bits inside the RTF payload, both, in send and receive direction. RTCP shall 
not be used for AMR-WB Rate Control in a Circuit Switched Core Network. 

10.4 GSM_EFR 

GSM_EFR shall be packed according to IETF RFC 3551 [17]. 

The coding of SID frames is based on the coding of Speech frames by setting the 95 bits of the so called "SID- 
Codeword" all to "1", see TS 46.062 [30]. 

To avoid delay, a single frame (Speech or SID) shall be included in one RTF packet. Interleaving (redundancy) shall not 
be used, and a packetization time of 20 ms shall be applied. No_Data frames shall not be sent. 

DTX shall be supported in send and receive direction. 

NOTE: RFC 3551 [17] does not support the concept of Bad Frame Indication. Therefore missing GSM_EFR 
frames in the AoIF downlink direction (e.g. discarded by a network node due to the missing bad frame 
indication) need to be properly treated within the BSS before sending downlink on the radio interface. 
Details are not specified. 

10.5 GSM_FR 

GSM_FR shall be packed according to IETF RFC 3551 [17]. 

The coding of SID frames is based on the coding of Speech frames by setting the 95 bits of the so called "SID- 
Codeword" all to "0", see TS 46.012 [28]. 

To avoid delay, a single frame (Speech or SID) shall be included in one RTF packet. Interleaving (redundancy)shall not 
be used, and a packetization time of 20 ms shall be applied. No_Data frames shall not be sent. 

DTX shall be supported in send and receive direction. 

NOTE: RFC 3551 [17] does not support the concept of Bad Frame Indication. Therefore missing GSM_EFR 
frames in the AoIP downlink direction (e.g. discarded by a network node due to the missing bad frame 
indication) need to be properly treated within the BSS before sending downlink on the radio interface. 
Details are not specified. 

10.6 GSM_HR 

GSM_HR shall be packed according to [22]. 

The options specified in [22] are not applied on AoIF, but set to pre-defmed values as follows: 

A single frame (Speech or SID) shall be included in one RTF packet, EEC and Interleaving (redundancy) shall not be 

used. Encryption shall not be used, a packetization time of 20ms shall be applied. No_Data frames shall not be sent. 

DTX shall be supported in send and receive direction. 

NOTE: [22] does not support the concept of Bad Frame Indication. Therefore missing GSM_HR frames in the 

AoIF downlink direction (e.g. discarded by a network node due to the missing bad frame indication) need 
to be properly treated within the BSS before sending downlink on the radio interface. Details are not 
specified. 

10.7 PCM 

FCMU and PCMA shall be packed according to IETF RFC 3551 [17]. 

A packetization time of 20ms shall be applied for FCM on AoIF. The packetization time is not negotiated for AoIP. To 
avoid delay, a single frame of 20ms shall be included in one RTF packet. Interleaving (redundancy) shall not be used. 

The usage of DTX for PCM-coded speech is not allowed on AoIF. 
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